Program-controlled units such as microprocessors, microcontrollers, signal processors, etc., have been known in numerous forms for many years.
A known problem of program-controlled units is that, in many cases, faults (operating errors or “bugs”) that occur during execution of a software program cannot be readily localized and/or remedied.
One previously used (and in some cases still used) approach for localizing and remedying faults occurring in a program-controlled unit is to produce a special “bond-out” version of the program-controlled units that are used for program development. Bond-out versions of program-controlled units are specially-produced in small batches, and differ from the standard mass-produced versions of the respective program-controlled units in that they include more input and/or output terminals, and the additional input and/or output terminals are connected to locations on the program-controlled unit that are not freely accessible in the standard version of the program-controlled unit. Typically, these additional input/output terminals are connected to the processor core of the bond-out version. As a result, information on internal states or processes of the program-controlled unit (e.g., addresses, data and/or control signals generated in the processor core, such as the respective current state of the program counter) that are typically not accessible in the standard version, can be output from the bond-out program-controlled unit, and evaluated outside the program-controlled unit. By evaluating the information it is possible to trace the profile of the processes occurring within the program-controlled unit, as a result of which faults occurring in the program-controlled unit can be localized and corrected.
However, the use of bond-out versions is associated with a series of disadvantages. In particular, the bond-out versions of program-controlled units are larger and more expensive than the standard production versions and, what is more important, the bond-out versions generally do not behave in precisely the same way as the standard versions. Therefore, problems that occur in bond-out versions may not arise in corresponding standard production versions, and problems may arise in the standard production versions that do not arise in corresponding bond-out versions.
For this reason, in some cases, another approach has been adopted in which standard production version program-controlled units are equipped with on-chip debug resources that facilitate the extraction of information from the program-controlled unit core for debugging purposes. These on-chip resources also facilitate outputting (“off-loading”) the extracted information from the program-controlled unit, or storing the extracted information in special memory arrays provided on the program-controlled unit. The outputting and/or storing operations are performed using an interface that includes only a small number of pins, which in some cases are also be used for other purposes.
FIG. 2 is a simplified block diagram showing a conventional program-controlled unit (microprocessor) 200. Program-controlled unit 200 is a microcontroller and comprises a core C, peripheral units P1, P2, P3 which are connected to the core C via a first bus BUS1, storage devices S1, S2, S3 which are connected to the core C via a second bus BUS2, debug resources DR which are connected to the core C, and an interface SS which is assigned to the debug resources DR, and via which the debug resources DR output data that is to be output to an external device and via which the debug resources DR are controlled by the external device (not shown).
The peripheral units P1 to P3 are, for example, an A/D converter, a timer, a coder, a compression device, a Controller Area Network (CAN) interface, or other units that can be integrated into microcontrollers, and the storage devices are, for example, a RAM, a ROM and a flash memory.
The debug resources DR are preferably capable of outputting what is referred to as trace information. For this purpose, the debug resources DR monitor for conditions that can be predefined from outside the program-controlled unit occurring within the core of the program-controlled unit, and whenever the condition or one of the conditions is fulfilled, addresses, data and/or control signals, which can be predefined from outside the program-controlled unit, are output from the program-controlled unit without interrupting the operation of the program-controlled unit. As a result it is possible, for example, but by far not exclusively possible, for the debug resources DR to output the data that is then fed to the core from the program-controlled unit whenever the core wishes to read data from a specific address or a specific address area.
In general, the debug resources DR also carry out further actions which are necessary or helpful for localizing and remedying faults which occur in the program-controlled unit. As a result, the debug resources DR are, for example, capable of stopping the program-controlled unit when specific conditions occur, for example when a specific program counter reading is reached, and reading out or changing the contents of registers of interest.
Such debug resources, also referred to as On-Chip Debug Support (OCDS) modules, are known, so further details will not be described.
Owing to the increasing significance of the presence of debug resources in program-controlled units, a standard which is referred to as “The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface” was defined for the corresponding interface (e.g., interface SS) in 1999 by the IEEE Industry Standards and Technology Organization (IEEE-ISTO), by means of which interface the debug resources can exchange data particularly efficiently with a analyzing device (e.g., a workstation) that is provided outside the program-controlled unit, for example with a debug control unit or emulation control unit, or with a measuring device such as, for example, a logic analyzer.
The debug resources and the NEXUS interface make it possible to detect and remedy faults occurring in program-controlled units with a relatively small amount of expenditure.
Nevertheless, the design and the operation of the debug resources DR can be very costly and complicated, especially in the case of relatively complex program-controlled units, for example in the case of program-controlled units with multiple cores. It is problematic here in particular to acquire and output the trace information: it may be necessary for a very large quantity of trace information to have to be output from the program-controlled unit in order to be able to localize and remedy faults occurring in the program-controlled unit, and furthermore it may also prove very complicated or even impossible to define the conditions whose occurrence determines the outputting of trace information.
What is needed is a program-controlled unit that facilitates efficient trace (e.g., debugging) operations while minimizing the amount of chip area required for on-chip debugging resources.